今天要完成什麼

Meeting Coordinator 將自然語言、Calendar 查詢、多輪選擇與核准串起來。目標不是讓 AI 擅自塞一場會議，而是縮短來回找時間的行政工作。

使用者可以說：「幫我找明天下午半小時，討論 gas-claw 發布。」

實作

Agent 先從 memory 取得工作時間與預設時區，再用 calendar.list 查詢明天下午。將已有活動轉為 busy intervals，計算至少三十分鐘的空檔，最多提出三個。

使用者回「第二個」後，session 取回選項，組成 calendar.create。Policy 產生 approval，顯示標題、開始、結束與說明。只有核准後才建立。

若缺少日期、長度或標題，Agent 應追問；不能默認建立全天活動。

動手試試看

先把 personal memory 設為「工作時間 09:00–18:00、時區 Asia/Taipei」。在明天下午建立兩段 busy event，再從 LINE 說「幫我找明天下午半小時討論發布」。把 Agent 提出的三個時段與 Calendar 一一比對；任何重疊或超過下班時間都算失敗。

看到選項後不要完整複製，只回「第二個」。這一步驗證 session，而不是重新解析一個獨立命令。接著查看 approval summary，它至少要包含會議名稱、ISO 時間與人類可讀台北時間。核准前 Calendar event count 不變；核准後只增加一。

再測三個負面情境：只說「幫我安排會議」時應追問日期與目的；回「第四個」時應指出選項不存在；等 session 過期後回「第二個」應要求重新查詢。Agent 願意追問，比自信地排錯時間更重要。

驗證

測試行事曆已有 14:00–15:00 活動，助理不得提出重疊區間。選擇時確認 session reference；session 過期後回「第二個」應要求重述。

核准前後比較 Calendar event count，拒絕與重複核准都不得增加事件。

發布素材

• 聊天 Demo：「幫我安排下週與 Amy 的 30 分鐘會議」。
• 設計焦點：偏好、空檔、候選、短句追問與核准串成多步工作。
• 測試／失敗案例：沒有候選確認或參與者不明時不得建立邀請。
• 截圖證據：呈現候選時段、使用者短句選擇、核准要求與 Calendar 結果四個階段。
• 當日 Git tag：day-23。下一篇把會議紀錄轉任務。

安全與限制

第一版不自動邀請外部 attendees，因為那同時發送通知。跨多位成員真正找共同空檔需要 Calendar FreeBusy 與不同授權，留待後續。

模型若不確定時區必須詢問，錯一小時比多問一句更糟。下一篇把會議結束後的紀錄變成任務。

今天完成的是一個真正多步的 Agent 工作：讀偏好、查工具、提出選項、理解後續短句、等待授權、執行並回報。它沒有預先畫好的 workflow，但每一步都受到資料結構與 policy 約束。

記得在文章截圖中使用測試 Calendar，並把真實參與者與活動名稱遮掉。公開 Demo 的可重現性不需要犧牲個人行程隱私；使用虛構專案與固定時段反而更容易讓讀者對照結果。